The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The TELNET network protocol is defined in Request for Comments (RFC) 854 and RFC 855 of the Internet Engineering Task Force (IETF) and provides a general-purpose communication facility for transmitting and receiving data between a terminal and a network device such as a router or switch. Using TELNET, an operator can establish a connection to the device and issue commands in a command-line interface (CLI) language to the device. If the operator issues a command for the device to reboot, the device normally resets the TELNET communication port, causing disconnection of the TELNET session. Present techniques do not provide a convenient way to keep a TELNET session operational during a device reboot.
Modern computer networks rely on network transmission protocols for use in the exchange of information between clients and hosts. TCP is a transport layer protocol and is defined in RFC 793 and RFC 2001. Under TCP, a transmitter has the burden of flow control in response to network problems, including detecting network congestion and deciding when to retransmit.
In general, servers perform most transmitting, so a TCP process on a server performs most flow control decisions. Implementing flow control involves storing and maintaining state data describing the data packets already sent, tracking an amount of time taken to receive an acknowledgement from the client that particular data packets have been received, and scheduling checks to see if no acknowledgement has been received within a time-to-live value that is specified for each packet.
A disadvantage in the current implementation of TCP arises when a TCP connection is interrupted due to a reset or reboot. In the event of a reset or reboot, the TCP connection between the client and host times out, and the state of the TCP session is lost. In such cases, the reset or reboot is handled by invoking a new TCP connection at some point in the future in order to re-connect the client and host.
If the TCP connection is protected, then invoking a new TCP connection forces a re-authentication of the TCP connection. An authentication process determines whether a device requesting access to the network, or to a particular resource, actually is the device that it purports to be. If the device is authenticated, then depending on its identity, role, and other policy data, the device may be permitted to access the network, or selected resources within the network.
Additionally, upon interruption of a stateful TCP connection, involving a series of commands within a transaction, the location within the transaction is lost. The entire transaction must be performed again. For example, if a connection is lost during a database update transaction due to a reset or reboot, the update cannot continue, and the entire update transaction must be re-executed.
One approach used to relieve the TCP resumption issue has been to modify the TCP protocol itself to include a “migrate” request for handling resumption of existing TCP connections, as described in A. Snoeren et al., “Fine-Grained Failover Using Connection Migration,” MIT Laboratory for Computer Science, available online in the file “migrate-failover.pdf” in the folder/papers of the Internet domain “nms.lcs.mit.edu”. The “migrate” request effectively moves a connection to accomplish failover.
However, extending the TCP protocol to include such a “migrate” request to accomplish session resumption generally requires modifying software programs hosted on client devices that implement the TCP protocol. In many cases, such modification is not desirable or feasible because of the large number of deployed client devices.